It appears to make sense to move the guts of OTrunk to EMF, eclipse modeling framework.

Why

• Better authoring system - emf can generate eclipse authoring system
• Better support for object schema specification - makes authoring easier and less error prone
• More developed serialization - I believe this includes concepts of modularizing the xmi input files.
• Easier for beginning developers to understand.

Why not?

• Introduces more dependencies
• Requires code generation, which increases the initial barrier for creating new object types.

Intermediate approach

To start with I'll try using EMF as a OTDatabase implementation. This will allow us to use the better xml format, and cross document references. It will also push the ID system used by OTrunk to be more portable.

Doing this will require using the solutions to 2 of the issues below: containment and XML properties.
Inorder to phase in EMF.

Issues with moving to EMF

Containment

The issue here is that EMF requires static containment specification. This means that a feature has to set to be containing or not containing in the EObject definition. A instance of the EObject cannot decide if a particular feature should contain another instance or just reference that instance.

After a discussion on the EMF users news group. It appears the best way to deal with this is to have a common superclass (EDynamicContaimentObject) for all of the objects in the OTrunk system. And that superclass will have a single 0..N containment freature. Perhaps called dynamicContainmentContents. Objects which extend this one will use references for all of their freatures.

The InternalEObject of the EDynamicContainmentObject will modify the behavior of eObjectForURIFragmentSegment and eURIFragmentSegment so if the object is stored in the dynamicContainmentContents and it is referenced by another feature in the object then the other freatures path is used to refer to the object.

Finally the XMLSerializer will be modified so the dynamicContainmentContents is not written out if its objects are referenced by other parts of the same object. This last bit will probably be tricky especially in the case of lists.

XML Properties/Features

I saw a reference in the emf news group about handling xml elements which are not emf objects, but I didn't read it enough to know if will work here. In the short term these elements can marked to be written out as nested elements, but they will still get escaped. That will be really frustrating to look at for our xml authors.

User Data Proxies

Services (dependency injection)

Memory Management

Templating